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M0DE++ 
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AVERAGE 10 FRAMES FOR 
STABLE KV. (ALGORITHM) 



X 



GET RESOLUTION. 
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if CiTop < 1 MinzeroConAC) 
iMinZeroConAC = iTop; 

if (iBottom > tMaxZeroConAC) 
iMaxZeroConAc = iBottom; 

if CiLeft < iMinZeroConTransverse] 
iMinZeroConTransverse = iLeft; 

if CiRight > iMaxZeroConTransverse) 
imaxZeroConTransverse = iRight; 

lterator++; 
} 

// Following is in pixels 

int iZemSeperationAC = iMaxZeroConAc - iMinZeroConAc; 
int iZeroSeperationTransverse = iMaxZeroConTransverse - 
iMinZeroConTransverse ; 

if (dPixPerMM == 0.0) // cannot allow divisno by zero. 

return FALSE; 
// Following is in Millimeters 

double dMeasuredDiameter = (double)pOuterStar->AvgDiameter() / 
dPixPerMM; // dPixPerMN is in INI file 

double dZeroContrastAC = (double) iZemSeperationAC / dPixPerMM; 

double dZeroContrastTransverse = (double) iZeroSeperationTransverse/ 
dPixPerMM; 

char units 0 = * Millimeters""'; 

LogEntry(PAppName, FuncName, PLogEntryType [ELogl, ELog, 
"ACZeroContrastDistance = %4.1f %s", dZeroContrastAC, units); 

LogEntry (PAppName, FuncName, PLoqEntryType [ELog], Elog, 
"TransverseZeroContrastDistance = %4.1f °/os", 
dZeroContrasTransverse, units); 

double dMagnification = dMeasuredDiameter / dActualDiameter; 
LogEntry (PAppName, FuncName, PLogEntryType [ELog], ELog, 
"Magnification = %4.2P, dMagnification); 

dFocalSpotAC = (dAngle/57.3) * 

dZeroContrastAC/ (dMagnification - 1 .0); 
LogEntry (PAppName, FuncName, PLogEntryType (ELog), ELog, 

"ACFocalSpot = %d.1f %s", dFocalSpotAC, units); 

dFocalSpotTransverse = (dAngle/57.3) * 

dZeroContrastTransverse/ (dMagnification - 1.0); 
LogEntry \(PAppName, FuncName, PLogEntryType [ELog], Elog, 

"TransverseFocalSpot = %d.1f %s", dFocalSpotTransverse. units); 
return TRUE; FIG. 15A 
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return FALSE; 
if ( lAverageFrames 0 1 

return FALSE; 
if ( IFindBackground 0 ) 

return FALSE; 
if ( IFindStar (] ) 

return FALSE; 
if [ IFindlnner () ) 

return FALSE; 
if ( !plmgPrc->ReLoad 0 ) 

return FALSE; 
if ( !plmgPrc->FindQuadrants (pGuadrants) 

return FALSE; 
if ( !plmgPrc->ReLoad 0 J 

return FALSE; 

if ( !plmgPrc->FindZeroslnQu3drants (pBuadrants.pZeroContrastSet) ) 

return FALSE: 
if ( IFindFocalSpot 0 ) 
return FALSE; 

BOOL 

StarPhan : =findhocaiSpot 0 
( 

char FuncName 11 = "StarPhan: finoFocalSpot': 
LogEntry (PAppName, FuncName, PLogEntryType [EDebug], EDebug, 
LogMsgl [EntryToFunctionl ) ; 

TISArrayAsVectorlterator <lmgObj> lterator(*pZeroContrastSet) ; 

Iterator.Restart 0 ; 

int iMinZeroConAC = MAXINT; 

int iMaxZeroConAC = MAXINT * -1 ; 

int iMinZeroConTransverse = MAXINT; 

int iMinZeroConTransverse = MAXINT * -1 ; 

while (Iterator) { 

ImgObj *plmgObj = Iterator.Current 0 ; 

int iTop = plmgObj->TopBound 0 ; 

int iBottom = plmgObj->BottomBound 0 ; 

int iLeft = plmgObj->LeftBound 0 ; 

int irlight = p!mgObj->RightBound 0 ; rsr , A cri 

rib. lob 
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DISPLAY PROCEDURE 
I 



GetReslutionModes(SEG.PIane) 

SHOULD RETURN TABLE WITH ALL 
APPLICABLE MODES TO MEASURE AND 
THEIR MINIMUM RESOLUTIONS. 




FIG. 18A 
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DISPLAY PROCEDURE AND TELL 
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TUBE CALIBRATION ] 
(QUICK PROCEDURE) , 



DISPLAY PROCEDURE AND TELL USER TO 
PUT IN PHANTOM. (THICKNESS FROM DB) M 
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GET PMT HV (DTU) 



FIG. 20B 
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EVENTS AT 
SENDfRSJTE 



SEND PACI 
SEND PAft 
SEND PACKET 3 
SEND PACKET 4 
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RECEIVE BACKET 1 /SEND ACK1 
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WINDOW SLIDES 4 AT A TIME. 
WINDOW SLIDES AFTER ACKNOWLEDGEMENT 
THAT ALL 4 PACKETS WERE RECEIVED. 



FIG. 25B 



START-UP PSEUDOCODE 

DISABLE ALL INTERRUPTS 

SELECT THE FIRST BANK IN THE EPROM CHIP. 

INITIALIZE THE FPGA 

DOWNLOAD THE FPGA PROGRAM FROM EPROM TO THE MAPPED ADDRFSS OF THE XILINX 
PERFORM DIAGNOSTICS: 

- TEST RAM2000 

- TEST RAM6000 

FAILURES ARE REPORTED VIA THE LED. 

INITIALIZE THE SCI (SERIAL COMMUNICATION INTERFACE) 

- SELECT THE FIRST BANK OF THE RAM2000 AND RAMBOOO. 

- SET UP THE TIMER OUTPUT CAPTURE TO INTERRUPT EVERY 10 
MILLISECONDS. (START CLOCK) 

- ALLOCATE AND INITIALIZE THE NETWORK RECEIVE AND SEND BUFFERS. 

- INITIALIZE THE SCI INTERFACE. VERIFY THAT THE INTERFACE IS ATTACHED TO THE 
OPTICS AND NOT THE SCM. 

ENABLE INTERRUPTS. 

ENABLE THE TRANSMITTER ON THE SCI AND ENABLE THE RECEIVER INTERRUPT. 
* WAIT FOR PACKETS FOREVER (CONTINUOUS LOOP) IF PACKET IS RECEIVED, 
PROCESS THE PACKET. 
LOOP AGAIN* 
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DIAGNOSTIC TEST UNIT NETWORK AND 
SYSTEM 

This application is submitted with a microfiche Appendix 
consisting of one (1) microfiche with twenty-eight (28) 5 
frames. 

TECHNICAL FIELD 

The invention described herein relates to the monitoring, 1Q 
maintenance, and repair of vascular x-ray imaging systems 
or any similar system in which a number of distinct equip- 
ment modules are interconnected to form a functioning 
system. 

BACKGROUND OF THE INVENTION 15 

A typical vascular system consists of a patient table, an 
operator console, a control panel, and a high tension trans- 
former. These components are costly to service. The 
increased costs are a direct result of the trend toward 20 
modular systems. A modular design allows the buyer to 
customize a system to meet his individual requirements, but 
at an increased cost since repair and maintenance is more 
complex and must also be tailored to the individual system. 
The cost factor alone makes vascular systems primary 25 
candidates for development of cost saving diagnostic tech- 
niques and systems. 

Repair and maintenance requires that the field service 
engineer must have the technical manuals and repair proce- 
dures immediately available to him or her at the site to 30 
research any eventuality that may occur. Again, however, 
modularity becomes a factor. Since a variety of modules 
may be used in a typical vascular system, technical manuals 
and procedures for each module must be on-hand. This can 
represent a substantial amount of paper. 35 

SUMMARY OF THE INVENTION 

The present invention is an apparatus for communicating 
with a plurality of devices, in which a a plurality of 4Q 
programmable distributed test units (DTUs), each commu- 
nicating with an associated one of the plurality of devices, 
communicate with one another by way of a network, pref- 
erably an optical network. A system monitor unit commu- 
nicates with the plurality of programmable distributed test 45 
units by way of the network, programs each of the plurality 
of programmable distributed test units to function in a 
selected manner, and gathers information obtained by the 
plurality of programmable distributed test units, as 
programmed, from the plurality of devices. 5Q 

Each of the plurality of distributed test units include a 
standardized controller unit which is programmed by the 
system monitor unit, and a sample control module which is 
controlled by the programmed controller unit, and which is 
adapted to communicate with a corresponding one of the 55 
plurality of devices. 

Using the network of DTUs, connected to selected vas- 
cular devices, such as the dosimeter and control console, the 
DTUs gather and transfer data to the system monitor. The 
field service engineer connects a field service notebook 60 
(laptop computer) to the system monitor to access data 
gathered from the DTUs, Using the gathered data, accurate 
measures of system performance are developed which can 
easily be monitored and recreated, yielding "optimum" 
performance levels based on preset benchmarks. Through 65 
the electronic database storage capabilities of the system 
monitor, the field service engineer is provided with a support 
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system and reference materials, including component lists, 
manuals, and current software releases, that allow for 
quicker, less cumbersome and more accurate repair of the 
vascular system. 

The present invention can be used in connecting with an 
automated system which reduces the probability of errors 
occurring during manual data transfer, decreases hard copy 
support and technical data which the field service engineer 
has to carry to the site, and, allows the system monitor to 
perform the highly accurate performance data analysis 
required, thus reducing human error in diagnosis and repair. 

Such a diagnostic system enhances the efficiency of 
troubleshooting and repair and leads to shorter down times, 
thereby reducing costs and improving customer satisfaction. 
The system is also non-invasive so that it can collect data 
from the test points while the vascular system is in use. This 
allows field service engineers to proactively detect and 
correct system performance deterioration before the system 
fails. 

An offsite Technical Assistance Center (TAC) can be used 
to contact the system monitor remotely to access the DTU 
network to check system operations, and to update the 
information stored in the system monitor. 

The present invention can be used to shorten evaluation 
time through automation when used with a diagnostic sys- 
tem which employs an expert system which comprises 
software in the system monitor processor that analyzes data 
gathered and stored from the DTUs. The expert system can 
refer more quickly to similar problem situations in the past 
and recall resolutions. The expert system is therefore able to 
provide the field service engineer with suggestions on how 
and where to work on the system. The expert system also 
anticipates when an incorrect procedure is run, and directs 
the field service engineer to alternative correct solutions. As 
a result, time consuming guesswork, and trial and error, 
normally associated with the repair process are reduced, 
thereby allowing faster repair or adjustment of the vascular 
system. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a diagram showing an example of the diagnostic 
system of the present invention. 

FIG. 2, is a diagram of an example of the diagnostic 
system of the present invention as connected to a vascular 
system. 

FIG. 3 is a conceptual diagram of the on-site portion of the 
diagnostic system of the present invention, depicted in the 
lower circle, and the oflsite support provided by the TAC, 
depicted in the upper circle. 

FIG. 4 is a diagram of the diagnostic system of the present 
invention, configured in a star arrangement. 

FIG. 5 is a perspective and cross-sectional view of a 
generalized DTU module. 

FIG. 6 is functional block diagram of the microprocessor 
module common to each DTU module. 

FIG. 7 is functional block diagram of the power module 
common to each DTU module. 

FIGS. 8 is a schematic diagram for the Sample Control 
Module common to the kV,mA DTU, PMT DTU, dosimeter 
DTU, and master DTU. 

FIG. 9 is a table of the master pin assignments for the 
multi pin connector used in the DTUs. 

FIG. 10 is a diagram of the DTU microprocessor memory 
map consisting of RAM and EPROM memory. 
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FIG. 11 is a diagram of the communication data flow Assistance Center (TAC) 19, conceptually shown in FIG. 3, 

between the network and a sample control module as is a further component of the present invention, 

controlled by the DTU microprocessor. System Architecture 

FIG. 12A is a block diagram of a dosimeter DTU. As shown in FIGS. 1 and 2, the preferred embodiment of 

FIG. 12B is a block diagram of an operator console DTU 5 the dmgnostic system of the present invention 10 in its 

connected to the operator console. sim P lest form * a senes of 12 continuously gathering 

„ . , „ „ performance data at specified test points on the vascular 

FIG. 13 is a conceptual diagram of the functions per- system u and feedkg ^ Mormation back t0 the system 

formed by the system monitor. mQnitor 16 M shown {q fiq 2> a vasculaf system u used 

FIG. 14 is a flow diagram of the Resolution procedure. 10 for x-ray procedures may include a collection of modular 

FIGS. 15 A and 15B is the problem isolation algorithm equipment such as a high voltage tension transformer 78, a 

used for the resolution procedure. patient table 17, a control panel 32, and a console 30. A 

FIGS. 16 and 16B are flow diagrams showing the Focal dosimeter 28 may also be used with the vascular system 14. 

Spot Test procedure. T" e DTU Network 13 and the system monitor 16 are located 

FIG. 17 is a flow diagram showing the Half Value Test 15 on " site ^ d £ e c °™f c * d 10 the e 1 ui P ment in * e ^ asc _ ular 

procedure system 14. The DTUs 12 are connected to each other by a 

" A n , . , rt . , fiber optic network 24. In the preferred embodiment, the 

FIGS. MA and 18B are flow diagrams showing the Quick fib£f Qptic netWQrk 24 useg T0TX173/T0RX173 and 

Tube Calibration Check procedure. T0CP172 fiber optic cable available from Toshiba America 

FIG. 19 is a flow diagram showing the Check Max ERR 20 Electronic Components, Inc. located in Irvine, Calif. The 

procedure. maximum length of the fiber optic network 24 between each 

FIGS. 20A, 20B, and 20C are flow diagrams showing the DTU 12, is ten meters. A field service notebook 18 is 

Flouro Dose Data procedure. brought to the site by the field service engineer and is 

FIG. 21 is a conceptual diagram showing the session connected to the system monitor 16 by an ethernet connec- 

layer, data link layer, and physical media connections 2 * tion 20. A graphical user interface (GUI) 22 is provided on 

involved in communication between two DTUs of the the field service notebook 18 which enables the field service 

present invention. engineer to communicate directly with the DTU Network 

13 

FIG. 22 is a diagram showing the components of a data * „ . _ _ _ , . . 

link layer packet of FIG 21. M e°°cept™Uy shown in FIG. 3 additional technical 

i-™ • i- i- . , i 30 support, performance statistics, expert knowledge, and 

FIG. 23 is a diagram of the DTU network protocol f i ■ -i ui « •* - *C m u c 

datalink frame com osition of FIG 21 external data is available off-site in the TAC 19 by way of 

at i rame composition o a moc j em 26, or other suitable data line. The offsite 

FIG. 24 is a diagram showing the composition of the SU pp 0rt is available to the on-site field service engineer, and 

session layer packet of FIG. 21. assists in the effective functioning of the diagnostic system 

FIGS. 25A and 25B are diagrams showing the "sliding 35 G f the present invention, 

window" technique of increasing the reliability of data Referring to FIGS. 1 and 2, the ability to sample system 

transmission. data is made possible by DTUs 12 positioned at pre- 

FIG. 26 illustrates a start-up pseudo code for the DTUs. determined test points of the vascular system. For example, 

FIG. 27 is a diagram showing a generic start-up sequence DTUs 12 are positioned on the components of the vascular 

for a generic DTU. 40 system 14 such as the dosimeter 28, the console 30, the 

FIG. 28 is a diagram showing a DTU network annotation control cabinet 32, and the high tension transformer 34. 

session in accordance with the present invention. Each test P oint has a different DTU which is adapted to 

FIGS. 29A, 29B, 29C, 29D, 29E are sample screens from monitor P artic u ula J P"™**" of the associated ^mponent. 

SmartBook, the graphical user interface software presented For the dosimeter 28 has a dosimeter DTU 38 since 

to the field engineer upon logging onto the system, and 45 ^ ^ information is being gathered The DTU Net- 

t-t^ ™ . „ ..... . • work 13 is connected to a master DTU 34 which is con- 

HG. 30 is a flow chart diagram showing the menu options nected tQ ^ ffl monitQr 16 b a ^ ^ cMe ^ 

available to the field service engineer m the system of the sucfa as a ranve ' ntional 25 _ pin ^ 

present invention. The DTUs n afe connected - m a closed loop ^ 

FIG. 31 is an operational sequence diagram of the 50 | ne loop beginning and ending at the master DTU 34. A star 

"Troubleshoot" process of FIG. 30. combination, shown in FIG. 4, may also be used, which 

FIGS. 32A, 32B and 32C are flow diagrams for the eliminates some of the conceivable shortcomings of a series 

"Utilities" option of the diagnostic software of the present connection. 

invention of FIG. 30. In the hardware configuration of FIG. 2 the master DTU 

55 34 has a parallel port 40A, through which it is connected to 
the system monitor's 16 LPT port 40. The LPT port 40A uses 
four bits for input and another four bits for output data. The 

As shown in FIG. 1, the diagnostic system of the present master DTU 34 has an optical receiver & transmitter 54 for 

invention 10 comprises three major components: 1) a hard- communication with the fiber optic network 24. The master 

ware network of distributed test units (DTUs) 12 that can be 60 DTU 34 converts the digital signals it receives from the 

attached to predefined test points on the various modules system monitor 16 into the optical signals for the DTU 

which make up the vascular system 14; 2) a system monitor network 13. As data is received back from individual DTUs 

16 that receives and manipulates data from the DTUs 2; and 12, the master DTU 34 converts the signals from optical to 

3) a field service notebook 18 (a conventional laptop digital form and passes them to the system monitor 16 for 

computer) that serves as the field service engineer interface 65 analysis. 

with the system monitor 16 and enables the user to access In operation, the master DTU 34 sends data to the first 

the diagnostic system of the present invention. A Technical DTU 12 in the loop, the first DTU 12 retransmits the data to 



DETAILED DESCRIPTION OF THE 
INVENTION 
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the second DTU 12 and so on until the last DTU 12 sends fiber optic network 24; 2) monitoring input to the test point; 

the data back to the master DTU 34 to complete the loop. and/or 3) controlling a test point so as to maintain a given 

Cost is the primary advantage of a serial DTU 12 network value. For instance, the DTU 12 can act as a positive 

since only one fiber optic network 24 is required to connect feedback control system where the output is fed back as an 

all of the DTUs 12 in the loop. 5 input until a certain predetermined value is reached. Thus, 

The disadvantages of this approach are: a) one powered- for example, if the user wants to increase the radiation of the 

down DTU can disable an entire network loop; and b) when dosimeter 28 to a certain value, the dosimeter DTU 38 

transmitting, some distortion to the optical pulses may occur increases radiation incrementally until the specified output 

which can degrade high speed optical communication to a value is reached. 

slower mode. These disadvantages can be addressed by 10 The microprocessor module 46 is integrated with the 

using a combination of star/loop network configurations as power module 48 and a test-point-specific SCM 50. The 

shown in FIG. 4. multi-pin connector 52 provides the necessary signals to 

A star/loop optical network is shown in FIG. 4. This control the SCM 50 from the microprocessor 44. The 
embodiment uses four or more optical input/output channels preferred architecture of the microprocessor module 46, 
to allow all DTUs 12 vital to the diagnostic system to be is shown in FIG. 6, includes: an optical receiver & transmitter 
accessed by individual links of the fiber optic cable network 54, a microprocessor 44 such as Toshiba model 68HC11A1 
24. Secondary DTUs 12 can also be connected in a loop. or equivalent, an EPROM 58, a bank of RAM 2000 memory 
Direct access to the primary DTUs 12 prevents one mal- 56A, a bank of RAM 6000 memory 56B, a bank of RAM 
functioning 12 DTU from disabling the entire network. A 8000 memory 56C, and a field programmable gate array 
disadvantage of the star configuration is the additional 20 (FPGA) 64. The microprocessor 44 communicates over the 
optical cable required for the separate connections. Each data/address bus which is connected to the multi-pin con- 
loop can have a dedicated master DTU circuitry assigned to nector 52. FIG. 9 provides an example of the multi-pin 
it similar to the master DTU 34 described in connection with connector assignments for each of the DTUs 12. 
the closed loop embodiment of FIG. 2. Alternatively, a The optical receiver & transmitter 54 converts light pulses 
multiplex arrangement can be employed in which one set of 25 received from the fiber optic network 24 into electrical 
master DTU circuitry is shared by the various loops. signals recognized by the microprocessor 44 communication 
Distributed Test Units ports. As shown in FIG. 6, microprocessor 44, operating in 

The DTUs 12 will now be discussed in greater detail with the expanded multiplexed mode, provides access to external 

reference to FIGS. 5-11. DTUs 12 are portable data collec- RAM, 56A, 56B, 56C and EPROM 58, and I/Os. A typical 

tion units which are designed to be connected to predeter- 30 microprocessor memory map is illustrated in FIG. 10. 

mined points on the vascular system 14 without affecting the Each DTU 12 sends and receives data using two 

system's normal operation or the quality of the images 68HC11A0 serial links in the microprocessor 44: the Serial 

produced in the system. DTUs 12 are the "senses" of the Communication Interface (SCI or RS232) 60 and the Serial 

diagnostic system of the present invention, which collect Peripheral Interface (SPI) 62 as shown in FIG. 11. A 

data and pass it back to the system monitor 16. 35 cross-bar switch 64 is used to connect the optical link, and 

As shown in FIG. 5, three basic modules are piggy- the electrical link to the test points, to the RS232 60 ports or 

backed to make up a DTU: 1) a microprocessor module 46 the SPI 62 ports as dictated by the format of the information 

(MM); 2) a power module 48 (PM); and 3) a sample control being exchanged between the system monitor and the test 

module (SCM) 50. The modules are preferably connected by points. Cross bar switch 64 A is implemented as part of the 

stackable multi-pin connectors 52, shown in FIG. 5. A DTU 40 FPGA 64 as shown in FIG. 11. Code/decode Logic 65 

12 can be tailored to a specific test point by selecting and converts signals in MOSI/SCK format into Rx/Tx format 

stacking the appropriate SCM module 50 together with a and vice versa. 

microprocessor module 46 and a power module 48. The Instead of permitting all traffic on the network to pass 

microprocessor 46 and power modules 48 preferably remain through microprocessor 44, the SPI 62 receives information 

constant for each DTU 12. Also included are LEDs 104 45 from the optical receiver and retransmits the signal to the 

(shown in FIG. 1) built into the DTUs 12 which provide optical transmitter 54. The retransmitted signal is modulated 

status information and indicate whether the DTU 12 is again to compensate for optical pulse width distortion. (See 

operating after power-up. PAL retransmit switch 53.) In this way, a number of DTUs 

The microprocessor module 46 can include a Toshiba 12 can be connected in series without accumulating pulse 

68HC11AO microprocessor 44, operable off of battery 50 width distortion. 

power, with memory and optical input and output capability A generic DTU 12, can sample eight analog signals (0 to 
for connection within the network. The DTU 12 has analog 2.5 V range). Microprocessor 44 is equipped with an internal 
or digital inputs and outputs for connection to a component A/D converter 66. Analog data coming from the test points, 
of the vascular system 12, such as a dosimeter, at least one travels through the multi-pin connector 52 to the micropro- 
pair of which is optical 55 cessor 44 which is coupled directly to the multi-pin con- 
Each of the test points of the vascular system 14 at which nector. Analog data is then converted into digital format via 
DTUs 12 are located serve different functions; therefore, the analog/digital convenor 66 within the microprocessor 
different types of SCMs 50 are used. However, the power 44. The SCM 50 uses the External Data/Address Bus with 
modules 48 and microprocessor modules 46 are common to Chip Select Logic from the DTU 12 (address range 0800- 
each DTU 12. Although the general functions of all DTUs 60 0FFF, FIG, 7A) to interface with another DTU. The first four 
12 are similar, input requirements and levels of operation (Aq — h5V, A x — BATT.l, A^ — BATT.2, A3 — hl2V) input 
(voltages and values) may vary. channels monitor the power module 48 (FIG. 5). The first 
The pre-determined test points at which the DTUs 12 are monitors the +5V power supply voltage. The second and 
installed, are the points that are deemed most important in third monitor two batteries utilized within the DTU 12. The 
achieving the best possible image quality. Each DTU 12 65 fourth monitors the internal DC/DC converter voltage. The 
serves several functions, including: 1) listening for com- last four analog channels can sample data from any of the 
mands from the system monitor 16 received through the test points. 
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Each DTU 12 is preferably equipped with its own power 
module 48 having a battery 68 to provide necessary data 
retention for up to an hour, and a 24 v DC input 70 (FIG. 5). 
The battery is charged from an internal DC/DC converter 72. 
During "power on" of a DTU 12, the 24V power applied to 
input 70 can originate either from an external power supply 
or from one of the DC power lines inside the vascular system 
14. The DC/DC converter 72 converts a 24V input voltage 
into a 12V output voltage with 500 mA maximum current. 
If a 24V power source is not accessible from the machine, 
an external wall-plug transformer with 24V DC output is 
used. The converter has a 500V 3000V IN/OUT isolation 
rating. A schematic of the power module 48, which is 
common to each DTU, is shown in FIG. 7. 

The power module 48 is connected to the DC/DC con- 
verter 72 through a relay switch 74. If a high noise immunity 
is required, the power module 48 can be physically discon- 
nected from the DC/DC converter 72 and powered from the 
internal battery 68 for the brief period needed to acquire data 
during an x-ray exposure. 

DTUs 12 assume their special qualities from the SCM 50 
which they carry. A schematic of the SCM 50, as shown in 
FIG. 8, is common to the kV,mA DTU 76, the master DTU, 
the dosimeter DTU 38, and the PMT DTU 80. 

As shown by way of example in FIGS. 12A and 12B, the 
selection of the appropriate SCM 50 allows the generic DTU 
12 to function as a dosimeter DTU 38 or another specific 
DTU type such as a console DTU 88, depending upon its 
placement in the vascular system 14. (See FIG. 2). Data 
from the test point, such as from a Dosimeter 28 is received 
in the DTU 12 through the test point connection 51 on the 
SCM 50. Switch 200 is controlled by commands on lines B4 
and B5 to switch between a reference voltage and the test 
point signal. Divider 59 provides full scale and scaled levels 
of the signal from switch 200 to instrumentation amplifiers 
202. 

Instrumentation amplifiers 202 then drive lines AIN6 and 
AIN7 on multipin connector 52. The data is then sent 
through pins AIN6 and A1N7 on the multi-pin connector 52 
to the microprocessor module 46. The SCM 50 is equipped 
with a RS232 connection 55 for communication with a 
monitor or the field service engineer's laptop computer. A 
MAX 232 RS232 chip 57 converts the data signal to and 
from the RS232 format to a ±5V format used by the SCM 
50. The following are examples of the types of DTUs 12 and 
their respective SCMs 50 used in the diagnostic system of 
the present invention: 

kV,mA DTU 

The SCM 50 on the kV,mA DTU 76 may be connected to 
the TERMINAL-A PWB located on a HV Generator Tank 
78 (high tension transformer) or to the FEEDBACK PWB 
(See FIG. 2.) A kV,mA DTU 76 measures voltage and/or 
amperage at the test point 51. The SCM 50 provides an 
analog interface between the test points and the DTU 12. A 
set of operational amplifiers converts the mA signal to a 
voltage level which is proportional to the current level. 
Similar circuitry differentiates the +kV/-kV signal to pro- 
vide an absolute kV signal. The mA amplifier must operate 
within a 4-1500 mA signal range (Fluoro/Radiography 
modes). Therefore, programmed amplification ratio is pro- 
vided through a programmable register divider 59, FIG. 8, in 
order to accommodate the different ranges. 

Photo Multiplier Tube DTU 

The photo multiplier tube (PMT) DTU 80 measures the 
voltage that goes into the PMT80A. A simple op amp circuit 
can convert the PMT voltage to the levels measured by the 
microprocessor module 46 (similar to the kV,mA SCM). 



Dosimeter DTU 

The Dosimeter DTU 38 (shown in FIG. 12A) is typically 
connected to the dosimeter 28 to measure the input radiation 
to the imaging rube. The Dosimeter DTU 38 uses an RS232 
5 link to control the 35050A or equivalent dosimeter 28, set 
the proper range and mode, request data and transmit that 
data to the system monitor 16 via the fiber optic network 24. 
The SCM 50 (shown in FIG. 8) for the Dosimeter DTU 38 
is designed for a Keithley dosimeter but can be modified if 
10 another type of dosimeter is used. This SCM 50 uses a 
device similar to a MAXIM MAX 232 to convert 0-5V 
RS232 levels from the microprocessor 44 to the 9V levels 
required for the dosimeter 28. The dosimeter 28 is powered 
only from an internal battery and can not be turned on 
35 remotely. An operator must press the POWER ON/OFF 
button to activate it. However, the dosimeter turns itself off 
after a user-selected "unattended operation" period of 1 to 
255 minutes. 
Technique Selector/Console DTU 
20 The Technique Selector (TS/console) DTU 88 (shown in 
FIG. 2), connected to the operator console 30, queries the 
operator's console 33 to determine the technique selected by 
the operator. In addition, it monitors and reports all actions 
taken by the user. For example, it monitors and records 
25 technique selections such as the kV,mA settings, focal spot 
selections and x-ray tube selections, etc. The kV,m A stations 
or techniques can be selected and verified remotely from the 
TS DTU 88 without operator intervention, allowing full 
automation of numerous procedures. As discussed later, 
30 calibration of the vascular system 14 can be verified by 
comparing the DTU 12 measurements with the operator 
console 33 settings. 

The TS/Console DTU 88 also drives auto-testing of the 
operator's console 33. Using the test point measurements 
reported by the DTUs 12 the diagnostic system of the 
present invention can then compare these measurements 
with the settings recorded at the operator console 88 by the 
Technique Selector DTU 88 to assure accuracy. 
Master DTU 

The master DTU 34, shown in FIG. 2, is the first and last 
DTU 12 in the loop. The master DTU 34 provides protocol 
conversion/data buffering between the system monitor 16 
and the fiber optic network 24. The SCM 50, schematically 
45 shown in FIG. 8, for the master DTU 34 provides the 
necessary signals to link the master DTU 34 with the LPT 
port 40 of the system monitor 16 via a parallel port 40 A. 
Standard Lap-LINK or Interlink protocols are used for this 
communication. The SCM 50 for the master DTU 34 utilizes 
50 a buffer 204 for the digital signals between the multi-pin 
connector 52 and the LPT port 40 of the system monitor 16. 

Eight (8) data lines and one (1) strobe line are used to send 
input signals from the system monitor LPT 40 to the master 
DTU 34 parallel port 40A. SELECT, PAPER END, 
55 ACKNOWLEDGE, BUSY, and ERROR signals are used as 
the output signals from the master DTU 34 to the system 
monitor 16. The master DTU 34 uses an RS232-like proto- 
col to gather 4-bit (+1 strobe) nibbles and pack them into 
blocks acceptable to the network protocol. This allows a 
60 standard LPT port 40 to be used to simplify communication 
between the system monitor 16 and the fiber optic network 
24. 

The diagnostic system of the present invention can be 
configured without the master DTU 34 by replacing it with 
65 circuitry inside the system monitor which provides high 
speed optical communication between the system monitor 
16 and the DTU Network 13. 
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System Monitor 

The system monitor 16 (shown in FIGS. 1-2 and 13), 
through a master DTU 34 controls all of the other DTUS, 12 
and queries the DTUs 12 for information and processes the 
data they send back to it. The system monitor 16 can 5 
communicate individually with any of the DTUs 12. The 
system monitor 16 sends requests/commands to the DTUs 
12; in response, the DTUs 12 gather sample data from the 
equipment to which they are assigned, respectively. The 
system monitor 16 can determine when changes are occur- 10 
ring in the vascular system 14 by analyzing the data pro- 
vided by the DTUs 12 . The system monitor 16 can also 
command a DTU 12 to reconfigure itself to another type of 
DTU 12. 

The system monitor 16, shown conceptually in FIG. 13, is 
is a computer having a parallel port interface (LPT) port 40 
for connection to the master DTU 34 via a multipin cable 
connector 36, and an ethernet connection 20 for connection 
to the field service notebook 18. The system monitor 16 
hardware includes a CD-ROM storage 94 or equivalent; 20 
multimedia capability; a modem 96; an Ethernet connection 
20; a sound board with speakers 98; graphics capability; a 
hardware key 100; and a bar code reader 102. The system 
monitor 16 may also boot from the CD-ROM 94. The system 
monitor 16 preferably operates on a "Microsoft" Windows- 25 
based software. It may also operate on next generation 
software platforms such as WINDOWS '95 or UNIX. 

As shown in FIG. 13, the system monitor 16 controls all 
of the major system functions of the diagnostic system. All 
of the information and functions necessary to run the diag- 30 
nostic system of the present invention 10 with the exception 
of the software graphical user interface (GUI) 22, shown in 
FIGS. 29A, 29B, 29C, 29D, and 29E, are contained within 
the system monitor 16. Current and past performance infor- 
mation files for this system are stored in the on-site database 35 
110. The remote access capability 111 that allows this site to 
. talk to and be monitored by the TAC 19 is contained in the 
system monitor 16. The CD-ROM 94 contains documenta- 
tion (manuals and procedures), equipment specifications and 
video support necessary to perform site service activities. 40 

The remote access function 111 also enables remote users 
to transfer files from the system monitor 16, e.g., error logs, 
site history information, access the system monitor 16 
database, execute remote functions such as diagnostics or 
DTU 12 control, receive software revision information, 45 
schedule execution of DTU 12 control functions (i.e. a 
remote command to the system monitor 16 such as "sample 
DTU #2 every ten seconds), and schedule system perfor- 
mance execution. The system monitor 16 also runs self- 
diagnostics, and diagnostics on CD-ROM access, the DTU 50 
12 network, the LPT port 40, the serial port 108, and the 
ethernet connection 20. 

When the field service engineer connects the field service 
notebook 18 to the system monitor 16 via the ethernet 
connection 20, network data can be accessed. Diagnostics 55 
are provided through the system monitor 16 for trouble- 
shooting and maintaining the DTUs 12. The system monitor 
16 also assists the field service engineer with diagnostic 
procedures. Both the field service engineer and the TAC 19, 
can contact the system monitor 16 remotely via modem 96 60 
to access the DTU 12 network and check system operations. 
The system monitor 16 may also initiate contact with the 
TAC 19. The TAC 19 may also send electronic mail or 
technical bulletins to the system monitor 16 to be read by the 
field service engineer. 65 

After the system monitor 16 has analyzed data sent to it 
from the DTUs 12, it can automatically send the results via 
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modem 96 to the TAC 19. If, for some reason, the TAC 19 
line is busy, the system monitor 16 spools (queues) the data 
for later transmission. The system monitor 16 also allows 
users to schedule the sending of data logs and files from the 
system monitor 16 to the TAC 19. For example, the system 
monitor error log and activity log may be scheduled to 
transmit every eight hours. 

The system monitor 16 can analyze test point data such as 
dose, signal amplitudes, resolution, and field uniformity sent 
to it from the DTUs 12, At installation or calibration, the 
field service engineers enter acceptable values for each of 
the parameters (test points). Acceptable dose values, for 
example, could be between 0.08-0.09. These values, once 
entered, are stored in the system monitor database 110. 
When directed to do so, the system monitor 16 reads current 
values from the corresponding DTU, such as the Dosimeter 
DTU 38 then passes the value read to an expert system 
residing in the system monitor 16. The expert system 115 
compares the values read to the values set and determines 
whether the values are within the acceptable range. Deci- 
sions made by the expert system 115 then determine what 
procedures or actions the user is next prompted to take 
during repair and maintenance of the vascular system. 

The system monitor 16 can run a multitude of diagnostic 
procedures which reduce the guess-work of system repair. 
As shown by the way of example in FIG. 14, the "Resolution 
Procedure" guides the field service engineer through an 
analysis process to correct the resolution of images. Video 
images, from an x-ray, such as of small arteries are displayed 
on screen for a physician's review. Sometimes the quality of 
the image is poor such that it is of little or no value to the 
physician. In such a case, the poor image could be caused by 
a bad image tube, which costs about $40,000 to replace, or 
it could be a bad x-ray tube, which costs significantly less. 

The resolution procedure performs a series of isolation 
techniques to determine the true cause of the problem. The 
procedure displays instructions on the field service engineer 
notebook computer. The field service engineer inserts a 
phantom object in the x-ray image area. The phantom object 
is a lead screen with wires having predetermined spacing 
and predetermined thicknesses. Using an algorithm written 
in C and C++ language, shown in FIGS. 15A and 15B, the 
resolution procedure determines at which point the resolu- 
tion of an image can be measured (normal mode, magnified 
I mode, or magnified II mode). If the resolution can be 
measured at any of the three modes, then the image tube is 
good. The resolution procedure then executes other proce- 
dures such as "Display Master Objective Lens." If the 
master objective lens is good, then a "Check Focal Spot 
Size" procedure shown in FIGS. 16A and 16B is executed. 

In an effort to correct the resolution problem, a field 
service engineer may have thought the image tube was bad, 
and erroneously replaced it, when in fact the filament of the 
x-ray tube was defective. The present invention 10 avoids 
such errors by anticipating the possible causes of a given 
problem, and automatically excluding/eliminating incorrect 
solutions. 

Other procedures run by the expert system, such as Half 
Value Test, which, e.g., determines the hardness of the x-ray 
beam, Quick Tube Calibration Check, Check Max Entrance 
Exposure Rate, and Flouro Dose Data procedures, are shown 
in FIGS. 17, 18A, 18B, 19, 20A, 20B, and 20C, respectively. 

Those skilled in the art will readily recognize that these 
procedures are merely examples of the many such proce- 
dures which can be stored on the system monitor 16 and 
executed by the expert system 115. These procedures are run 
on a commercially available software package, entitled 
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NexPert, produced by Neuron Data Corp. located in Palo Images"; 3) "HW Key Information"; 4) "Error Log"; and 5) 

Alto, Calif. A sample of the source code (using NexPert's "Site History". All of these functions, represented by 

own code language) for the expert system 115 is included in on-screen buttons or icons, are accessible from the displayed 

microfiche form in Appendix A. screen. Wherever possible, accelerator keys are provided for 

The system monitor 16 also has security functions. 5 the functions. (The term "Accelerator keys" is used here to 

Remote users, e.g. the TAC 19, and users connecting to the mean a keystroke or a combination of keystrokes that can be 

system monitor 16 via the field service notebook 18, are used in place of pull down menu commands or click-on 

authenticated via a user login and user password in con- buttons.) 

junction with a hardware key 100 attached to the parallel "Get Images" enables a TAC engineer to connect to a site 

port 106 on the field service notebook 18. This authentica- 10 and retrieve images. There is an option of looking at the 

tion information is kept in the system monitor database 110. image as an icon before retrieving it, but this icon may be 

A temporary hardware key is provided for installation and somewhat less detailed than the original because of its 

testing of the diagnostic system 10. Upon installation, the smaller size. (The smaller image size allows faster transfer), 

field service engineer makes a confirming call to the TAC 19 The TAC engineer can also retrieve just the image header 

which, in turn, makes the key site-specific. 15 instead of the full image. "Display Images" enables the TAC 

The expert system 115 also utilizes the performance and engineer to display the images retrieved from the site. Once 

history information in the system monitor database 110. The displayed, "windows level" controls to adjust image param- 

system monitor database 110 stores an error log, an activity eters become available. "HW Key Information" enables the 

log, a problem resolution log, a results log, providing results TAC engineer to connect to a site and call up an on-screen 

from system evaluation tests, hardware key information, a 20 snapshot of the site's key contents. "Error Log" allows the 

remote connection log, a site history log, and system moni- TAC engineer to browse through the site's error log. "Site 

tor module version information, containing version and History" provides site history from data stored on site, from 

revision information on each process and software release. site information stored in a TAC database 112, and, in the 

Collectively, this information is used to support expert future, from site history stored in the ASSIST database 114. 

system diagnostics. 25 "Site History" stored on site includes process history/ 

Field Service Notebook status, key update information, key status, error messages, 

The field service notebook 18 completes the diagnostic system performance parameters, DTU records, etc. Site 

system 10 of the present invention. As shown in FIGS. 1-2 history from the TAC database 112 includes problems 

and 13, when the field service engineer arrives on site the encountered, their fixes, etc. When the TAC engineer selects 

field service notebook 18 is connected to the system monitor 30 this option the display area differentiates between the three 

16 with an ethernet connection 20. Then, using a graphical sources of information either by color or by fonts. From 

user interface software tool 22, the user can communicate "Site History" users may connect directly to a site to update 

with the system monitor 16 and access all of its diagnostic file logs if necessary. 

and maintenance functions, including the individual DTUs Through a series of database server functions the TAC 

12. The field service engineer notebook 18 includes: a 35 database 112 maintains complete information about all sites, 

microprocessor such as an "Intel 386" or "486" or equiva- All of the following functions have graphing capabilities so 

lent portable computer; graphics capability; "Windows"; that the user can plot displayed information on a variety of 

and a windows-based Graphic User Interface (GUI). In the graphs (pie, line, bar). Through the database server 

preferred embodiment of this invention, a GUI such as functions, the TAC engineer can browse the "Site History" 

"SmartBook" from Toshiba America Medical Systems in 40 logs, browse through previous site results log from a site, see 

Tustin, Calif, is used. a history of hardware key updates for a site, and see when 

Technical Assistance Center the field service engineer has upgraded a selected site and 

The Technical Assistance Center 19 ("TAC") is the central the upgrade software version installed, 

information source for the diagnostic system 10 of the Network Protocol and Communication 

present invention. See FIG. 3. Tools are available to the TAC 45 As shown in FIG. 21, the DTU 12 network protocol 

engineers from a common user interface which allows the consists of three logical layers, a data link layer, 116, a 

TAC engineers to upload and view images as well as to session layer 118, and a network interface layer 119, oper- 

upload log files from the on-site system monitor 16 to review ating over a physical media layer, the fiber optic network 24. 

system performance. Complete site history as well as an After power-on the RS232 port 60 of the microprocessor 

on-line expert system is also available at the TAC 19. The 50 44, FIG. 11, is programmed to 9600,N,8,1 data format and 

technical experts at TAC 19 are available to assist the field the optical lines 55 are connected to the RS232 RxD and 

service engineers with immediate diagnostic system ques- TxD pins. Thus, each DTU 12 can be accessed by the fiber 

tions. optic network 24 using a standard RS232 protocol. Switch- 

The hardware for the TAC 19 includes: conventional ing between RS232 and SPI 62 interface formats can be 

personal computers (PCs) with internal modems, ethernet 55 controlled by software. Communication between the DTUs 

cards, 200 megabyte or more hard drives, CD-ROM drives 12 is done in data packets 120 such as those illustrated in 

(these can be attached to the file server to be used as a FIGS. 22-24. 

shareable resource), ethernet connections between work A data packet 120 arrives at the DTU 12 to which it is 

stations, a file server, a backup system, an uninterruptable addressed by way of physical media (e.g. fiber optic network 

power supply (UPS), and a laser printer. The TAC 19 60 24) and is initially handled by the network interface layer 

preferably uses a commercially available Novell network, an 119. Thereafter the Data-Link layer 116 of the receiving 

Oracle Database Server, a Neuron Data Expert System, and DTU 12 checks the checksum, checks for the correct 

Windows 3.1 software on all PCs. The TAC 19 workstations address, and receives the packet. Once that is completed, it 

are connected via ethernet and operate on the Novell net- sends the packet to its session layer. The data packet 120 

work. 65 consists of a preamble, start of frame delimiter, destination 

The following functions are available to the TAC user address, source address, data length field, data field, end of 

when connecting to a site: 1) "Get Images"; 2) "Display frame delimiter and two bytes for cyclic redundancy check - 
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sum (CRC) as illustrated in FIGS. 22 and 23. The packet 
length is determined by examining the data length field. 
Validation is then done by examining the frame start, frame 
end and the CRC fields. The frame start and frame end are 
known values. The CRC validation consists of calculating 5 
the CRC on the frame excluding the CRC fields and then 
comparing it with the embedded CRC. The CRC algorithm 
used for the data packets 120 is based on the "classical" 
CRC hardware circuit, conventionally known as "CRC- 
CCITT" polynomial (1021H). It is important to note that the 
CRC calculations for data packets 120 are done by software 
or hardware depending on the network interface selected. 
The CRC for the RS232 SCI 60 interface and the parallel 
port 40 is calculated by software, while the CRC for the SPI 
62 interface is calculated by the hardware circuitry residing 
in the FPGA 64. 15 

A DTU network protocol data link frame (DNP) uses the 
big endian as its network byte order. Thus the high-order 
byte is at the starting address. As an example, FIG. 23 shows 
the byte order used for data length and the CRC fields. It is 
important to note that this layer only uses the data portion of 20 
the frame to calculate the CRC. 

Data Link Layer 

The data link layer 116 is the lowest logical layer of the 
protocol. It performs the actual transfer of the data packets 
120. The data link layer 116 functions by receiving and 25 
encapsulating data from the session layer 118. As illustrated 
in FIG. 22, encapsulation includes attaching the address and 
calculating and attaching the checksum to the session layer 
data. The data link layer 116 then sends a data packet 120 
shown in FIG. 22, to the next DTU 12. 30 

The data link layer 116 provides three different data 
transfer options depending on a particular application's 
needs. The three data transfer methods are: reliable trans- 
missions with positive acknowledgement, transmission 
without acknowledgement, and reliable transmission with 35 
sliding window. 

Reliable transmission is based on the fundamental tech- 
nique of "positive acknowledgment with retransmission." 
Ill is technique requires the recipient to communicate with 
the source, sending back an acknowledgement message as it 40 
receives data. The sender keeps a record of every data packet 
120 it sends and waits for an acknowledgement before 
sending the next data packet 120. The sender also starts a 
user-defined timer when it sends a data packet 120 and 
retransmits the data packet 120 if the timer expires before an 45 
acknowledgement arrives. Up to three retransmissions will 
be attempted. For performance reasons, the received mes- 
sage is delivered to the session layer 118 which can send the 
acknowledgment and reply in one message thus saving half 
the time necessary to accomplish the work. The sender data 50 
link layer 116 always passes the acknowledgment 
(embedded reply) to the session layer 118 for further pro- 
cessing. In this mode, no buffering is used on the DTU 12 
nodes. A handle to the received message is passed to the 
application. The length of the message can not exceed the 55 
"DNP Maximum Transfer Unit" constant. The Open 
Network, Close Network, Annotate, Invoke Address, Invoke 
Name, Download, Upload and Memfill modules are imple- 
mented using the Reliable Transmission Service. 

Transmission Without Acknowledgement allows applica- 60 
tions to transmit messages without waiting for an acknowl- 
edgement. No retransmission of messages is done. The data 
link layer 116 provides a simple transmission service which 
transmits the message without waiting for an acknowledge- 
ment. It is the responsibility of the application program to 65 
confirm that the data packet 120 was received without errors 
at the destination. 
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The Reliable Transmission/Sliding Window Technique is 
used for larger transmissions than is possible with the other 
transfer methods. The "sliding window" technique is a form 
of positive acknowledgement and retransmission in which 
multiple data packets 120 are transmitted before waiting for 
an acknowledgement. As shown in FIG. 25 A, instead of 
acknowledging receipt of each individual data packet 120, 
packets 1-4 respectively, the receiver site waits until four (4) 
data packets 120 have been received, spools each acknowl- 
edgement and then sends one (1) acknowledgement to the 
sender site. The number of unacknowledged data packets 
120 at any given time is constrained by the window size and 
is limited to a small, fixed number. Once the sender receives 
the acknowledgement for the first four data packets 120, as 
shown in FIG, 25B, the window slides four at a time and the 
next series of data packets 120 are sent. 

Lost data packets 120 are retransmitted and acknowl- 
edged before the window slides. The sender encodes suffi- 
cient information in the data packet 120 indicating when the 
acknowledgement should be sent. When the sender retrans- 
mits lost data packets 120, it requests the receiver to send the 
acknowledgement immediately for every data packet 120. 

Unlike both the Reliable Transmission with Positive 
Acknowledgement and Transmission without Acknowl- 
edgement methods, with the Sliding Window method, all 
acknowledgements are done by the data link layer 116. The 
sender data link layer 116 accepts a large message from the 
session layer 118 and the receiver's data link layer 116 
delivers a large message to the receiver's session layer 118. 
If requests are too large, the data link layer 116 can break 
them up into data packets 120. 

Session Layer 

The Session layer 118 is the higher logical layer on the 
DTU network 13 protocol layer. It provides protocols for the 
two types of services needed in the DTU network 13: 1) 
, DTU network 13 protocol services standard for every DTU 
12; and 2) specific services which are defined by the type of 
DTU 12, e.g. kV,mA or dosimeter, etc. 

Data that the session layer 118 sends to the data link layer 
116 consists of two parts, data length and Data (which 
contains the header in addition to the data). The session layer 
118 uses only the data portion of the data packet 120. As 
shown in FIG. 24, based on the first two bytes of the header, 
the session layer 118 is able to determine the type of service 
requested of or by the DTU 12. The services include 
annotation, network check diagnostics, programs and mod- 
ules download, module invocation, memory dump, and 
DTU 12 time setting and debug sessions. 

Network Interface Layer 

The network interface layer 119, responsible for the data 
communication at the lowest level of the network, consists 
of device drivers and modules necessary to transmit and 
receive data packets 120. CRC calculations and validation 
are performed at this level such as the SCI 60 (RS232), SPI 
62, parallel port interface 40, and packet drivers. 

All data packets 120 with valid CRC and destined for the 
DNP address assigned to the local node, are accepted and 
passed to the data link layer 116. "Broadcast" data packets 
120 are also accepted. All other data packets 120 require no 
further processing and are dropped. The notable exception is 
the master DTU 34 which accepts data packets 120 that are 
destined to itself as well as to the system monitor 16. Data 
packets 120 destined to or from the system monitor 16 are 
routed over the parallel port 40 interface on the system 
monitor 16. 

DTU Software 

DTU software is broadly categorized into "Start Up" 
software which executes when the DTU 12 is powered on, 
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and "Services" software which executes when the system Data Bits: (8). Next, the network buffers are initialized. Two 

monitor 16 requests a service. Sample source code, using a buffers are required to receive and send data packets 120. 

combination of C and 68HC11 Assembly language, for a The buffers are allocated from BANK 0 RAM2000, 23 A. 

kV,mA DTU 38 is included in Appendix A . DTU Operation 

After Power On/Reset the 68HC11AO microprocessor 44 5 The "Start-up" sequence, shown in FIG. 27, is the process 

begins executing instructions (code). (See Microprocessor of initializing the DTUs 12. Each DTU 12 as directed by the 

Memory Map, FIG. 10). This software code: selects the system monitor 16 through the master DTU 34, runs self- 

EPROM 58 bank that contains code for the FPGA 64 such diagnostics and annotation. A portion of the "power on" 

as model No. XC3064, manufactured by XILINX, of San process is the annotation of the DTUs 12 in which they 

Jose, Calif., copies the FPGA code to the FPGA chip 64, and 3Q identify themselves as they pass a command packet 122 

runs self -diagnostics. Self-diagnostics begins with a through the DTU network 13, returning it back to the master 

memory test on the two RAM chips, 56A and 56B, in the DTU 34. 

DTU 12. If no network -disabling faults are encountered The annotation command enables configuration of the 

during diagnostics, the software initializes the serial port 54 DTU network 13. At startup all DTUs 12 determine their 

and waits in a continuous loop for any data packets 120 on status and their SCM's 50 status. At annotation time, the 

its serial port 54. The software selects bank 0 from the 15 status and identification numbers are encapsulated and sent 

memory 2000 chip 56A and sets up the necessary commu- as part of an annotation packet 124. The identification 

nication buffers. These buffers are used to receive data number for the DTU 12 and the SCM 50 is assigned at 

packets 120. The startup pseudocode is described in FIG. 26. EPROM 58 programming time and is kept in the EPROM 

The FPGA 64 performs logical functions according to 58. Both numbers are available for the software to read at 
programs loaded to it after power on. Programs may be 20 startup time. A sequence number for the DTU 12 is also 
downloaded from the system monitor 16 to the RAM added to the annotation packet 124. 
memory banks, 56A-56C of the microprocessor module 44. As shown in FIG. 28, the annotation packet 124 travels 
The FPGA 64 is memory mapped from address 0800 to from the master DTU 34, through the DTU network 13, 
0FFF (hex). Port A of the 68HC11AO microprocessor 44 is while the annotation information from each of the DTUs 12 
connected to various FPGA 64 control pins. The FPGA 64 25 is added to the annotation packet 124. Also, when the DTU 
is RAM configurable, i.e., the FPGA 64 configuration must 12 examines the annotation packet 124, it determines its 
be downloaded after power on. The configuration program sequence number in the DTU 12 network and binds that 
resides in the EPROM 58. The initialization process sequence number as its network number, 
involves resetting the FPGA 64 and then copying the con- The annotation session assumes that the fiber optic net- 
figuration from EPROM 58 to address 0800 (hex). 30 work 24 is in the open configuration and that the DTUs 12 

To reset the FPGA 64 the RESET (Port A bit 6) and understand that the annotation packet 124 must be retrans- 

PROGRAM_DONE (Port A bit 5) pins of the FPGA 64 are mitted after they add their annotation information. A DTU 

set to "LOW" for 6 microseconds, then restored to "HIGH". Memory Dump command provides the capability of request - 

The reset is successful when a LOW to HIGH edge is ing a memory dump of the DTU 12 memory. The system 

detected on the INIT (Port A bit 0) pin. The configuration 35 monitor 16 initiates a memory dump request to the DTU 12 

program is downloaded by writing one byte at a time to indicating the bank, starting address and the total number of 

address 0800. The FPGA 64 uses one pin to accept the data. bytes to dump. The DTU 12 then replies with an image of 

In order to properly download the program, the READY/ the memory. A sample of the EPROM 58 boot-up source 

BUSY pin (PORT A bit 1) must be checked to make sure it code, using a combination of C and 68HC11 Assembly, is 

is "ready" before writing the next byte to the FPGA 64. 40 included in Appendix A. 

DTU Self-diagnostics The system monitor 16 can download additional modules 

The present invention has an error reporting mechanism to the DTU 12, A download command provides the capa- 

to indicate any equipment or network failures. If an incon- bility of downloading a program module to any bank of the 

sistency occurs in the DTU 12 read/write processor the RAM chips on the DTU 12. The bank, starting address and 

system detects an unacceptable voltage level, a signal is sent 45 the number of bytes are specified. A module-invoke com- 

to the LED 104 on the corresponding DTU 12 to indicate a mand is the way the system monitor 16 instructs a DTU 12 

problem condition. The field service notebook 18 may also to execute a module that was downloaded to RAM memory, 

be connected directly to the RS232 terminal 55 on the DTU This command sets the DTU 12 time to the system monitor 

12 for local diagnostics. 16 time in seconds since 1970. 

When FPGA 64 initialization has been completed, DTU 50 Each DTU 12 performs and provides specific services 

12 self-diagnostics are performed. First the RAM memory based on the SCM 50 it contains. The general network 

test is performed by writing a unique pattern to each bank of services (such as check, open, close, annotation, DTU 

the RAM chips 56A, 56B and 56C, on the DTU 12. The memory dump, download, module invoke and set-time 

pattern is read back and compared. The pattern used for the commands) are provided by all DTUs 12 regardless of their 

test is the bank number. Because all of the banks are written 55 specific purpose. These general services are accomplished 

to and then read, the bank switching feature is tested through DTU 12 network commands. The maximum num- 

simultaneously. If an inconsistency occurs in the read/write ber of DTUs 12 in the network is 255; however, twelve is the 

process, the startup is halted and the error is reported to the preferable arrangement. 

LED 104. A network-check is initiated by the system monitor 16 

Next the battery voltage level and power supply level are 60 (via the master DTU 34). Since the fiber optic network 24 is 

checked. If there is an unacceptable voltage level, the startup normally closed (retransmit enabled) any data packet 120 

halts and the error is reported by the LED 104. A low but sent from the master DTU 34 should be received back by the 

acceptable one which still permits the electronics to function master DTU 34. The type of data packet 120 is set to indicate 

within spec, voltage is reported to the system monitor 16, but that this is a "pass through" data packet requiring no 

does not halt the startup. 65 processing or replies. If the data packet 120 transmitted is 

The SCI interface 60 is initialized with the following received back by the master DTU 34, the fiber optic network 

setting: Baud Rate: 9600; Parity: None; Stop Bits: (1); and 24 is operational. 
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A network open command instructs all the DTUs 12 to 
disable their auto retransmit feature. Thus, the DTU 12 
retransmits any data packet 120 that is not addressed to it. 
The annotation packet 124 is an exception, as described 
above. The network close command instructs all the DTUs 5 
12 to enable the auto retransmit feature. 

Depending on the service requested from a specific DTU 
12 the system monitor 16 dynamically downloads the appro- 
priate software module to the DTU 12 after annotation of the 
network to set the DTU 12 function. Thus, each DTU 12 10 
connected to a different piece of equipment has a specific 
software package, executive module, tailored for its func- 
tion. 

For example, the executive module in the kV,mADTU 76 
waits for a request from the system monitor 16 to sample is 
either kV or mA. Once the request is received the analog 
port (Pin 0 for kV and Pin 1 for mA) is sampled and the 
values are returned in the reply data packet 120. Similarly, 
the executive module in the PMT DTU 80 waits for a request 
from the system monitor 16 to sample the PMT voltage. 20 
Once the request is received the analog port (Pin 0) is 
sampled and the value is returned in the reply data packet 
120. 

The master DTU 34 software module has a parallel port 
40A through which the master DTU 34 communicates with 25 
the system monitor 16. The master DTU 34 waits for the 
strobe signal from the system monitor 16 received through 
the system monitor LPT port 40 and then reads eight bits (1 
BYTE). Once the bytes read make up a frame, the frame is 
routed to the fiber optic network 24. The reverse is similar 30 
except that half a byte is transferred at a time. 

System Operation 

The user interface between the field service notebook 18 
and the system monitor 16 is accomplished by the GUI 22, 
preferably the Toshiba in-house software program Smart- 35 
Book from Toshiba Medical Systems, Inc. in Tustin, Calif. 
SmartBook is developed on a commercially available soft- 
ware package known as Multi Media Toolbook 
("Toolbook") produced by Asymetrix in Belvue, Wash. A 
sample of the SmartBook source code, in Toolbook *s own 40 
language, is included in Appendix A. SmartBook allows the 
field service engineer access from his field service notebook 
18 to the diagnostic system 10 of the present invention once 
his authorization has been checked. Through pull-down 
menu options available through SmartBook, samples of 45 
which are shown in FIGS. 29A-29E, the field service 
engineer has access to a variety of options. 

The field service engineer can immediately connect the 
field service notebook 18 to the system monitor 16 and, 
using SmartBook software, gather data and operate the 50 
expert system 115 residing on the system monitor 16 
through the serial port 108. FIG. 30 illustrates the sign on 
sequence, and the options thereafter available to the field 
service engineer. First the ethernet link is established 
between the field service notebook 18 and the system 55 
monitor 16, step 140. 

To bring up the SmartBook tool the field service engineer 
plugs in a customized hardware key 100 to the parallel port 
106 of his notebook, step 142. This hardware key 100 
authorizes the user access to the diagnostic system 10, and 60 
has an expiration time built into it. If the key has not expired 
SmartBook brings up a login screen (not shown) with 
prompts for a user name and a password. 

Once connected, and security access validated, the field 
service engineer signs on to the diagnostic system 10 of the 65 
present invention which resides in the system monitor 16, 
step 144. FIG. 29A illustrates a typical screen image initially 
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presented to the field engineer, including a graphical user 
interface main menu 22 and a status bar 134. The main menu 
22, presents several menu options on a menu bar including: 
Configure 126; System Diagnostics 128; Mew 130; and 
Utilities 132. 

A Status Bar 134 (FIG. 29 A) above each screen displays 
whether the site has received any new mail since the last 
time the user logged in, a system status area 136 showing the 
current status of the vascular system, a Warning or Emer- 
gency Error area 138 that shows messages requiring user 
attention, and a Process area 140 displaying the process that 
is currently running. Once the user is logged in, the Status 
Bar 134 is displayed with all subsequent screens. This 
provides the user access to key information irrespective of 
activity. It also provides consistency between screens and 
eases the process of user familiarization. 

The various other options of the main menu 22 will now 
be described in greater detail. Referring to FIG. 30, the 
configure option 126 allows the user to do the initial 
configuration and then any reconfiguration necessary at a 
later stage. During installation the user must configure the 
Site 146, the X-ray system 148, and the DTU network 13, 
step 150. After installation only the DTU network 13 may 
require re -configuration, see step 152. This is necessary each 
time a DTU 12 is moved to a different test point. 

For "Site Configuration," step 146, the user enters site 
specific information that is stored both in the system monitor 
database 110 and the TAC 19. The X-ray configuration 
option, step 148, allows the user to enter information about 
any system component that needs to be replaced. Selecting 
the X-ray configuration option causes a still picture of the 
X-ray room to be presented on the field service notebook 
screen, showing the various components making up the 
vascular system 14. A tool bar display of various x-ray 
system components is also available. With this display, the 
user is able to select the specific components that make up 
the vascular system 14 on this site. Those selections are 
positioned in pre-determined places on the display screen of 
the file service notebook 18 forming a system configuration 
unique to this site. This specific configuration can be saved 
in the system monitor database 110. 

Replaceable components have "hot" areas so that when 
selected (clicked on) the picture, the current part number, 
model number and serial number of the component are 
displayed. If that particular component is not in the system 
monitor database 110 the serial number field is blank and the 
user is prompted to type in the serial number of the new 
component being installed. A bar code reader 102, FIG. 13, 
to scan serial numbers and further reduce the possibility of 
error may also be used. Once the serial number is entered, 
the serial number, model number and part number are 
automatically cross-checked to ensure that the combination 
exists in the TAC database 112. Any discrepancy is com- 
municated to the field service engineer via a TAC-initiated 
e-mail message to the site and displayed in area 138 of the 
Status Bar. Henceforth, whenever the field service engineer 
logs in to this site, notification of any mismatches is pro- 
vided through the Status Bar "working and e-mail" area 138. 
The component part descriptions and their associated model/ 
serial numbers are automatically updated in the system 
monitor database 110 and the TAC database 112. 

Selecting the "VASPAC Configuration" option from the 
Configure 126 menu bar, brings up another sub -menu (See 
FIG. 30). This menu lists the most common post-installation 
configurations for the specific site and offers a menu of 
accessory tools. A Configuration screen is presented on the 
field service notebook which shows both a picture of the 
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x-ray room with test points marked and a tool bar on which 
various types of DTUs 12 are shown. The user can then drag 
and drop DTUs 12 to the various test points on the picture 
corresponding to the placement of DTUs on the system. If 
a non-compatible DTU is dragged to a test point, the 
mismatch is flagged as an error and the match disallowed. 
For example, a kV,mA DTU 76 cannot be used in place of 
a Dosimeter DTU 38. The user has the capability to 
customize, add and delete DTUs 12 from this tool bar to 
allow the software configuration to conform to the actual 
physical configuration of the vascular system 14. 

The multimedia accessories connected to the diagnostic 
system through the Accessories selection allows the user to 
notify the system of available hardware such as a camera, 
sound board, or video connected to the vascular system 14. 
Functions which depend on hardware that has not been 
identified as "available" are turned off. Hardware that is 
crucial to the operation of the vascular system is not select- 
able. In other words, if the vascular system won't operate 
without it, the function cannot be turned off. 

The "Systems Diagnostics" option 128 on the main menu 
(shown in FIG. 30) provides the user with the most common 
troubleshooting tools associated with an vascular system 14. 
The "System Diagnostics" option 128 allows the field ser- 
vice engineer to calibrate; do preventive maintenance; 
troubleshoot; view a system-specific component list; replace 
a part on the system; or develop "optimum" characteristics 
standards to allow the diagnostic system 10 to be returned to 
settings that the customer feels provide the best image. 
Through the "System Diagnostics" option 128, procedures 
such as those shown in FIGS. 14 and 16-20 may be 
executed. Sample menu screens from SmartBook showing 
access to representative procedures, such as "Resolution" 
and "Half Value Layer 1 ' are shown in FIGS. 29D and 29E. 

When the user selects "System Diagnostics," 128 a pic- 
ture of the Vascular system 14 is displayed on the screen of 
the field service notebook 18, such as is shown in FIG. 29C. 
All selectable components of that Vascular system 14 are 
identified as buttons, and action buttons are placed under- 
neath the Status Bar 134 for Calibrate 194, Preventive 
Maintenance 156, Trouble Shooting 158, Components 160, 
Snapshot 162, and Replacement 164. Thus, if the user wants 
to calibrate an X-ray tube the X-ray tube button and the 
calibrate button are selected. On-screen instructions consist- 
ing of text, flowcharts, and/or video clips to assist the user 
in completing the calibration process are then presented on 
the screen. 

If, for example, the field service engineer selects " trouble - 
shoot" the diagnostic system 10 of the present invention 
guides him through the evaluation process, providing 
on-line displays, information and suggestions as shown 
generically 31 (see also FIGS. 14, and 16-20). 

The "View" 130 option (FIG. 30) allows the field service 
engineer to access either "Mail" 166 or the on-line X-ray 
"Manuals" 168. Selecting "Mail" 166 allows the field ser- 
vice engineer to view and respond to new and saved mes- 
sages to the site, or view TAC 19 documentation updates. 
Selecting the "Manuals" 168 option allows the field service 
engineer access to X-ray technical manuals stored in the 
CD-ROM storage 94. These on-screen manuals contain text, 
flow charts, and both still and animated video clip illustra- 
tions. The field service engineer can browse through the 
technical data, view relevant video clips and even zoom in 
on a component seen in a still picture to get a list of 
sub-components, and be guided step-by-step through the 
repair or maintenance process. The text, still and video 
segments of the screen, are inter-related. 
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Through the "Utilities" 132 option shown in FIGS. 30 and 
32A, 32B and 32C, the field service engineer can look at Site 
History 170 which enables viewing of past and current site 
results, past system problems and how they were fixed, and 

5 an Error Log 178. An analysis log of past results is stored in 
the system monitor database 110 in a configurable Results 
Log, with any overflow automatically sent to the TAC 
database 112. This information allows faster repair time if 
the field service engineer can refer to fixes for a similar 

3Q problem which has occurred previously. The current system 
status such as errors logged, current activities, and any files 
that were spooled to be sent to the TAC 19 may also be 
viewed. 

The Fixes Log 176 contains a history of all problems that 
have been encountered at the site and how the problems 

35 were fixed. The entire log is stored in the system monitor 
database 110, with a copy of the log also being stored in the 
TAC database 112, Updates to the on-site database are 
automatically sent electronically to the TAC database 112. 
The Error Log 178 contains a list of errors in the vascular 

20 system 14 that have been logged at this site. The error log 
size is configurable, and error log overflows are sent auto- 
matically to the TAC database 112. The user is able to 
display errors: within a certain Range of time, of a certain 
level, with a certain number/string, and logged by a specific 

25 process. The user is also able to turn certain fields OFF while 
displaying all or a subset of the Error Log 178. For example, 
once all the errors associated with a certain level have been 
extracted, that field can be turned off to allow more infor- 
mation per line to be displayed. An error can be one of three 

30 levels Operator, Service and Debugging. The level displayed 
corresponds to the user. For instance, when a field service 
engineer displays the error log 178, all errors at the Operator 
and Service levels but not the Debugging level are dis- 
played. When a super user is logged in, errors at ALL levels 

35 are displayed. 

Via the "Status" utility 172, the user can view the current 
status of the diagnostic system 10 including errors logged 
180 by the current session, a log 182 of activities that 
happened in the current session, any files that were spooled 

40 (queued) 184 to be sent to the TAC 19, and the status 186 of 
the Hardware Key 100. The Status Error Log 180 has the 
same Operator, Service, and Debugging viewing capabilities 
as the Error Site History log 178. The Activity Log 182 has 
a "Date" and "Time" stamp, logging process name, and a 

45 message string. The user is able to search through the log 
and extract activities logged by a specific process. The 
Activity log 182 size is configurable. Overflows are auto- 
matically sent to the TAC database 112. Selecting the spool 
184 displays files that have been queued to be sent to the 

50 TAC database 112. Information displayed with each entry 
includes: name of the process that put the file in the queue, 
date and time the entry was spooled, date and time entry is 
to be sent, destination (where the file is being sent to), 
predicted transfer time, current status of the entry (Active or 

55 Pending), and size of the file. The user is able to edit the 
spool (queue) by Adding and/or Deleting entries. Added 
entries have a user configurable "Send Immediately" option 
or a "Schedule to be sent at <time>" option. Default sched- 
ules the added entry at the end of the current list. 

60 The field service engineer, through SmartBook, also has 
options to run various self-diagnostic tests to check the 
following key functions: the ethernet connection 20 between 
the field service notebook 18 and system monitor 16, the 
system monitor 16 and master DTU 34 connection, the fiber 

65 optic network 24, and system monitor 16 self-diagnostics. 
Therefore, one tool provides multiple service and repair 
functions. 
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Thus, through the elements described and arranged as test unit through which the system monitor unit communi- 

shown herein, the present invention provides for simpler, cates with the remainder of the plurality of programmable 

more cost effective, and more reliable repair and analysis of distributed test units, and further wherein a sequence of 

a vascular system. communicating information on the network originates and 

The terms and expressions which have been employed 5 e *ids with the master distributed test unit, 
herein are used as terms of description and not of limitation, 6 - ^ apparatus of claim 4 wherein each one of the 
and there is no intention in the use of such terms and plurality of programmable distributed test units includes 
expressions of excluding equivalence of the features shown means for receiving information from an upstream program- 
and described, or portions thereof, it being recognized that mable distributed test unit, and for relaying selected portions 
various modifications are possible within the scope of the 10 of the received information onto a downstream program- 
invention claimed. mable distributed test unit along with information originat- 

What is claimed is: m S w i tn tne one programmable distributed test unit. 

1. An apparatus for communicating with a plurality of 7. The apparatus of claim 2 wherein the plurality of 
devices comprising devices include test points and further wherein each of the 

a plurality of programmable distributed test units each « Polity of programmable distributed test units includes 

communicating with an associated one of the plurality means for momtormg the test point 

of devices' 8. The apparatus of claim 2 wherein the plurality of 

' devices include test points and further wherein each of the 

a network which penmts communication of mformation ^ of programmable distributed test units includes 

among the plurality of distributed test units; and ^ means for controlling the test point to ma intain a desired 

a system monitor unit communicating with the plurality of value at the test point, 
programmable distributed test units by way of the 9. The apparatus of claim 8 wherein the information 
network, wherein the system monitor unit programs communicated to a programmable distributed test unit from 
each of the plurality of programmable distributed test t he system monitor unit includes device control instructions; 
units to function in a selected manner, and gathers 25 and further wherein the controlling means control the device 
information obtained by the plurality of programmable m accordance with the device control instructions to main- 
distributed test units, as programmed, from the plurality tain the test point at a value designated by the device control 
of devices. instructions. 

2. The apparatus of claim 1 wherein each of the plurality iq j^q apparatus of claim 1 wherein the system monitor 
of distributed test units comprise 3Q un it maintains optimum performance data for the plurality of 

a standardized controller unit which is programmed by the devices which optimum performance data is customized to 

system monitor unit; and a user of the plurality of devices as a system. 

a sample control module which is controlled by the H. A distributed test unit comprising: 

programmed controller unit, and which is adapted to a standardized controller unit which is programmed by a 

communicate with a corresponding one of the plurality 35 system monitor unit; and 

of devices. a sample control module which is controlled by a pro- 

3. The apparatus of claim 2 wherein the network com- grammed controller unit, and which is adapted to 
prises an optical network interconnecting the plurality of communicate with an associated device, 
distributed test units. 12. The unit of claim 11 wherein said sample control 

4. The apparatus of claim 2 wherein the network com- 40 module receives data from said associated device. 

prises an optical network in which the plurality of program- 13. The unit of claim 12 wherein said sample control 

mable distributed test units are connected in series in a loop. module further controls said associated device. 

5. The apparatus of claim 1 wherein one of the plurality 

of programmable distributed test units is a master distributed * * * * * 
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